> > That's how I used to do it: modelling the windows...  But that was
> > way too slow!
>
> Slow rendering, or slow modelling?
Uhm...
Both!


> > Maybe, but what about more complex shapes?
> > Example: let's say I'm trying to model the birth of a planet.  A
> > planet with parts of it still hot and glowing, and parts of cold
> > stone.  I would use a pattern so I can easily give the glowing parts
> > a different texture.  With per-object post-processing, I really don't
> > know how I should do this...
>
> Use eval_pattern() or eval_pigment() to place spheres or some other
> fast-redering shape(or glows, which won't even need a post_process
> filter) at the right places? Use an isosurface as the target
> object?(Probably too slow...)
> Or just use media...

I didn't say it would be impossible to do so, I said it would be a lot
easier to have an effect_map.

> > But if it doesn't allow blending, I don't see why it would need more
> > memory than per-object based PP...?
>
> It would require a separate "post process map" for every filter
> controlled by a pigment, for one thing. And by removing the ability to
Aand per-object based PP wouldn't need that?

> blend between filters, you remove a most of the reason for having
> pigment controlled filters in the first place!
 I know, but I thought you said blending the PP would be too difficult.

> > One extra bit per pixel:
> > post-process this pixel or not.  Same as per-object PP.
>
> Wrong. At bare minimum, it would require storing some sort of post
> process filter ID, to specify *which* filter to run. Probably a pointer,
> unless you want to limit the number of filters you can use. Much more
> than "one extra bit".
OK, but that's a choice every user can make for themself...  I mean: if you
include the option to do a global PP, it wouldn't always need this amount of
memory, only if the user wants it to.  Or am I wrong again?

ZK
http://www.povplace.be.tf

Post a reply to this message